I am using Jdeveloper 11.1.1.3 and Oracle SOA 11.1.1.3, and creating BPEL processes.
Operating system: Windows 2008
RAM: 6 GB
The composite application having 5 BPEL process.
the problem is while deploying the application its taking too much time, average deployment time is more than 10 minutes.
Please suggest me is there any way to reduce the deployment time.
(Except this I do not feel system is running slow ther is any performance issue)
Alot of people have this problem when they are running the server locally, most people suggest that you don't do this incase you have atleast 8gm of RAM.
Most people however run the server externally to their PC however apart from getting a better PC or installing the server externally giving more memory to jdeveloper might help. The other thing to do is to close the applications you don't need. My guess is you have SOAPUI, Database, Jdeveloper, Server, Internet Browser, Documentation and more open.
To increase memory allowance.
Go to [jdevhome]\jdeveloper\ide\bin
Open ide.conf
And increase the memory to a suitable value : AddVMOption -Xmx[number of MB]M
Restart Jdev
Related
I have a dedicated Windows 2008 Server with 32GB RAM & Intel Xeon E3-1230 v2 processor and SQL Server 2008 (Standard Edition).
There's a heavy data import & cleaning process i.e importing data from CSV files which runs daily and whole process takes about 8-10 hours.
My problem is that ASP.NET MVC website which is hosted on this same sever gets slow for small periods during that import process. Most of the time, it runs fine, but in between, the site will become unresponsive and slow. The import process doesn't touch the database which the site uses.
What are the options for me to ensure my site runs smoothly throughout?
is it even possible to achieve, keeping in mind some very resource-heavy operations get performed during the data import on the same server?
The import process is a Windows application which uses SSIS packages to import data and after that runs server SQL Server stored procedures.
Ankit quick solution for your problem is to have 2 VM on your dedicated hosting server. One one VM you can host your website and another VM you can host you database and import process.
From performance perspective it is case by case as your problem is very generic and broad so community can't help but tip still you can follow.
For your website create separate application pool.
You can assign min and max CPU and memory utilization for your processes like import, IIS etc based on your need.
Check clock speed;whether it is matching between your processor and virtual memory. It doesn't matter how much virtual memory you have you need your RAM in sync with you processor cores.
As SQL Server Standard version supports max 4 cores of processors. Check how much cores you have in your dedicated server.
I have got some really good ideas from the community for my problem. Having two Virtual machines is a very good one but it's restricted by my lack of knowledge on the topic. Solution proposed by Anil in comments in also a good one that we can two seperate SQL Server instance and use Resource governor to restrict resources but for that we'll have to first upgrade to enterprise edition which is not feasible for us at the moment.
So keeping the cost in mind, we have decided to try Varnish. Plan is to get a separate Linux VPS and set Varnish there. Window Server will be the backend for Varnish. As once the data is prepared by our import process, our pages stays more or less static, I think we'll do good with this.
I am trying to migrate an application on a Weblogic server which already has an application in it. Please suggest if having two EARs in the same weblogic server is a feasible design
It is perfectly feasible and standard; however, there are one or two reasons why you might not want to do this.
One is file descriptor exhaustion. If one of the applications (EARs) runs out of file descriptors, it will probably crash / render inoperable the entire process, i.e. the entire Weblogic server.
Another is heap memory exhaustion; much the same problem occurs if one of the applications exhausts the maximum available heap memory.
Application servers try to isolate applications from each other, but cannot completely succeed at this due to the limitations of the JVM. Operating systems and virtual machine hypervisors are actually able to do a better job of isolating applications from each other.
We have the following setup:
Virtual server, Intel Xeon X5650 # 2.67Ghz (4 processors)
8GB RAM
Windows server 2008 Standard 64bit
Sql Server Express
IIS 7.5
Our database is only 200mb. We are running an ASP.net app. We recently ran into some performance issues, ~200 concurrent connections was causing 100% CPU usage (mostly consumed by IIS) and bringing the response time to around 20sec! After some tweaks to our code we have been able to run a load test from loader.io with 1500 concurrent users over 1 minute and our response time at the end was around 5 seconds and CPU was around 95%, again consumed mainly by IIS, our memory was sitting at around 4GB usage. However we are expecting bigger spikes than 1500, anywhere up to around 4000 users in a short amount of time.
My questions are the following:
1) Is this normal performance for our current setup? Our site is quite intensive on the database and we are using Entity Framework.
2) Would upgrading to Sql Web edition have any benefit seeing as though our Database is so small?
3) Do you think that this type of setup could handle 4000 users?
4) Any suggestions on what we could do to handle this load?
I know this is somewhat subjective, but any answers are much appreciated.
Is this normal performance for our current setup?
Depends on your code. Did you profile the code to make sure you dont have anything stupid in there?
Our site is quite intensive on the database and we are using Entity Framework.
Again, did you pofile to figure out you spend a lot of time in entity framework? It is slow, ut the question is what "intensive" means. This is what profilers are for.
Would upgrading to Sql Web edition have any benefit seeing as though our Database is so
small?
Help, my pizza comes too late. Wiould upgrade to a larger car help? You say yourself that you spend the time in IIS, not sql server.
Do you think that this type of setup could handle 4000 users?
You think my car is big enough? Note I don't tell you what I need it for. Without looking at usage patterns and your code - no idea. THAT SAID: the server is pathetic compared to what you buy today. As such, this is a irrelevant question - just upgrade if you have to.
Any suggestions on what we could do to handle this load?
Load test + profiler, optimize code. Get bigger server. Realize that we dont have crystal balls to figure out how good / bad / stupid your code is.
Number one question arising here, is: did you deploy RELEASE or DEBUG compiled binaries of your project?
Upgrade to WebEdition will not solve any problem here, since the difference in the versions is very simple: WebEdition is just throttled in the internal scheduler/etc. - so you will be just fine with the standard edition.
My experience is that the most crucial aspect of concurrent request is the amount of server memory and the consumption of this memory by your code.
As the physical memory is consumed, the server starts to swap from physical to virtual memory which slows down processing dramatically and leads to symptoms you describe.
I would start with putting another 8gb of ram into the server. In the meantime try to optimize your code so that less data is processed during requests or less memory is used. Also, move sql server to a separate machine so that there is no competition between iis and sql server when it comes to memory availability.
With your current machine, I doubt the problem is the IIS itself, but rather related to the way your app is designed and/or utilize frameworks. I personally learned just recently that IIS requests including multiple rounds trips to the database can be measured in hundreds of micro-seconds, not hundreds of milliseconds... A single locking bug, or unbalanced queuing can limit your application scalability and regardless of your hardware specs [https://twitter.com/michaelzino/status/454512110165184512].
Entity Framework is known for validating your models against the database schema for the first initial calls. I would suggest profiling your app layers, starting from the data access layer, or the intrinsic database calls, and going up.
We're running a custom application on our intranet and we have found a problem after upgrading it recently where IIS hangs with 100% CPU usage, requiring a reset.
Rather than subject users to the hangs, we've rolled back to the previous release while we determine a solution. The first step is to reproduce the problem -- but we can't.
Here's some background:
Prod has a single virtualized (vmware) web server with two CPUs and 2 GB of RAM. The database server has 4GB, and 2 CPUs as well. It's also on VMWare, but separate physical hardware.
During normal usage the application runs fine. The w3wp.exe process normally uses betwen 5-20% CPU and around 200MB of RAM. CPU and RAM fluctuate slightly under normal use, but nothing unusual.
However, when we start running into problems, the RAM climbs dramatically and the CPU pegs at 98% (or as much as it can get). The site becomes unresponsive, necessitating a IIS restart. Resetting the app pool does nothing in this situation, a full IIS restart is required.
It does not happen during the night (no usage). It happens more when the site is under load, but it has also happened under non-peak periods.
First step to solving this problem is reproducing it. To simulate the load, we starting using JMeter to simulate usage. Our load script is based on actual usage around the time of the crash. Using JMeter, we can ramp the usage up quite high (2-3 times the load during the crash) but the site behaves fine. CPU is up high, and the site does become sluggish, but memory usage is reasonable and nothing is hanging.
Does anyone have any tips on how to reproduce a problem like this in a non-production environment? We'd really like to reproduce the error, determine a solution, then test again to make sure we've resolved it. During the process we've found a number of small things that we've improved that might solve the problem, but I'd really feel a lot more confident if we could reproduce the problem and test the improved version.
Any tools, techniques or theories much appreciated!
You can find some information about troubleshooting this kind of problem at this blog entry. Her blog is generally a good debugging resource.
I have an article about debugging ASP.NET in production which may provide some pointers.
Is your test env the same really as live?
i.e
2 separate vm instances on 2 physical servers - with the network connection and account types?
Is there any other instances on the Database?
Is there any other web applications in IIS?
Is the .Net Config right?
Is the App Pool Config right for service accounts ?
Try look at this - MS Article on II6 Optmising for Performance
Lots of tricks.
Possibly better suited for "Rack Overflow", but from a developer's point of view, what are the advantages and disadvantages of running IIS (serving both legacy classic ASP and .NET) as a 32bit process instead of a 64bit process on a 64bit windows host?
The main advantage of 32/64 (iis/server) over 32/32 seems to be the ability to go up to 4gb in memory per IIS process.
The advantages I expect of 32/64 over 64/64 appear to be that it's easier to access legacy 32-bit in-process DLLs (of which we still have one from a partner vendor we can't move away from immediately) and perhaps a smaller memory footprint for the same code given smaller memory pointers.
Are there any performance benefits of 64/64 over 32/64 or anything else that would warrant a full switch now? Have I made any false assumptions here?
The only perf advantage to running IIS on 64bit vevrsus 32-bit is to allow access to a much larger memory address space.
If you are doing normal ASPX page processing, then it's likely you don't need to address more than 4gb from any single process. Suppose you run in 32-bit mode with a web-garden with multiple worker processes on the same machine. In that case each process can address up to 4gb.
The big advantage can come when you perform caching. A 64-bit process can maintain a huge in-memory cache (assuming you have the 32GB or more of RAM to support it) to allow you to cache complex page content or data, on the web server. This allows perf gains when the data is more expensive to generate than it is to retrieve - for example if the data is an elaborated form (let's say the result of a monte carlo simulation), or if the data resides off-box and the network IO time is much more expensive than cache-retrieval time.
If you do not use caching, then 64-bit IIS is not going to help you. It will require 64-bit pointers for every lookup, which will make everything a little slower.
64-bit servers are much more effective when used for databases like SQL Server, or other data management servers (let's say, an enterprise email server like Exchange), than for processing servers, such as IIS or the worker processes it manages. With a 64-bit address space, servers that need to manage data can keep much more of that data in memory, along with indexes and other caches. This saves disk IO time and elaboration time when a query comes in. Most Web apps don't need to address more than 4gb from a single process.
Maybe a useful analogy: In transport, an large SUV is like a 64-bit machine, while a regular, compact passenger car is like a 32-bit server. You can carry much more stuff in a large SUV, and it has a larger towing capacity, seating for 8 people, and a GVWR of 8600 lbs. But with all that, you pay. The truck is heavier. It uses more fuel. If you are only carting around 2 people and one duffel bag, you don't need an SUV. You'll be better off with the smaller vehicle. It can be speedier and more efficient.
I don't think you've made any false assumptions. But I'd say, no, there's likely to be no performance difference between any of the scenarios you outlined. 32 on 64 on Windows does not operate at a penalty. 64 on 64 may give some slight performance boost, but that's dubious. There may be some memory savings with a 32-bit process, but this is likely negated by the thunking required to run the process in the first place.
The only benefit is the DLL issue you mentioned. That could be a reason for upgrading as well (if you have something specifically 64-bit that you need to use).
I've had an experience where moving from a 32bit Windows 2003 Server to a 64bit Windows 2003 Server both running IIS 6 and the performance of the ASP.NET 3.5 website was unacceptable.
The 64bit server would run a clear 2 seconds behind the 32bit one consistently.
After switching IIS 6 to run as a 32bit worker process, the performance was equal and comparable once again.
I haven't verified it, but I think it might only apply to IIS6 win2k3, as testing I've done with IIS7 x64 (Vista) and a 64bit IIS worker process seems to perform just fine.
The process to swap to the 32bit process was quite simple. Here is the KB article with the supporting details:
http://support.microsoft.com/kb/894435/en-us
ASP.NET 2.0, 32-bit version
To run the 32-bit version of ASP.NET 2.0, follow these steps:
Click Start, click Run, type cmd, and then click OK.
Type the following command to enable the 32-bit mode:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
Type the following command to install the version of ASP.NET 2.0 (32-bit) and to install the script maps at the IIS root and under:
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
Make sure that the status of ASP.NET version 2.0.50727 (32-bit) is set to Allowed in the Web service extension list in Internet Information Services Manager.
See the KB article for setting back to 64-bit.
For memory availability, refer to this msdn blog.
Memory availability. For my application, we got what we needed switching from 32 bit process on 32 bit OS to 32 bit process on 64 bit OS, without the trouble of replacing 3rd party libraries. So, we stopped there. Benefits are: 1) 2-3x effective memory available to each IIS worker process and 2) In a 32 bit OS where the web site uses a lot of memory, other system processes and web sites compete for limited total memory. For your application, look at how much memory do your worker processes use. If each WP isn't using a lot of memory (well over 1GB), 64 bit worker processes won't help much.
For performance, I think you have to test your own applications in both configurations. Dave's post above indicates that you might have performance degradation with 64 bit. As cheeso notes, some applications may see benefits from caching (2GB + of cache is a lot, though). Except for limited and simple applications, I don't think we are going to be able to make performance generalizations. We might be able to point to specific technologies that perform better or worse.
Besides the obvious memory differences, 32 bit processes on a 64 bit OS have to run in something called "Windows on Windows" or WOW mode. It's basically a thunking/emulation layer. There is a performance penalty if you pay close enough attention.
This is actual advice from Microsoft: "We recommend that you configure IIS to use a 32-bit worker processes on 64-bit Windows. Not only its compatibility better than the native 64-bit, performance and memory consumption are also better."
Please refer to this link posted in one of the comments above and published 05/14/2020:
https://learn.microsoft.com/en-us/iis/web-hosting/web-server-for-shared-hosting/32-bit-mode-worker-processes
I cannot claim to understand exactly why, but this advice is very clear, with 64bit workers virtual address space is bigger so a 32bit worker is generally more efficient