Slashdot Mirror

It works quite well too. Next, please!

Have you ever looked at XML-RPC? There are at least 9 PHP implementations around.

Have you ever looked at XML-RPC? There are at least 9 PHP implementations around.

... is XML-RPC. A sort of lightweight SOAP. Very very useful for API's when you're doing cross-platform coding...

The site has loads of implementations of both server and client code, some in *very* obscure languages :-)

Simon.

You have only complained about a perceived problem so far, you need to isolate and identify your bottleneck(s). The best way to do this is through performance metrics:

Identify your problem with...

1. I suggest using Microsoft's "Performance Monitor", which gives you access to dozens of OS, IIS, .NET, Web Service, MSMQ and SQL Server performance metrics, from the simple CPU utilization and memory usage to the detailed such as .NET CLR Threads, SQL Server Cache Misses, IIS File Cache Hits. You can display performance metrics for multiple machines on the same real-time graph, so you could show database machine CPU, web server CPU, IIS Requests/Sec and SQL Server CPU on the same chart. This would give you a good start.
2. There is a .NET API to plug into "Performance Monitor"! Build your own metrics to be displayed with the ones provided by the system...your code may not be as efficient as you once though after you see your own metrics.
3. SHOW PLAN sql statement for SQL Server. It is build into Query Analyzer. It will tell you what indexes your queries use, and how long each step of your query takes so that you may optimize your queries/updates
4. SQL Server Profiler - This will show you ever statement that SQL Server is currently running, or you can filter based on a number of criteria and give you a look at their execution performance.

If your problem is that SOAP is too fat...

Use XML-RPC it is what SOAP used to be BEFORE it got FAT.

If your problem is Web Application...

Web Services are supposed to be STATELESS. If you are using any sort of state mechanism, it is going to make an impact on your performance. Be sure to turn off user sessions if you don't need them.

Is IIS configured properly? There are scaling settings in there to modify, this changes IIS's caching behavior (look under the "Performance" tab)

Have you set the Application Protection (under "Home Directory" tab), you can execute your site within the IIS process (Low Protection - high speed but if your app crashes it takes down IIS -- never seen this happen personally), within a thread pool (Medium Protection - crash won't affect IIS, but all your sites may have limited availability), or within its own process (High Protection - slowest, but if it fails, IIS and every other site keeps on operating)

Have you turned off logging if you don't need it?

Optimize the IIS Metabase, adjust settings you can't get to through the UI. Never heard of it? Learn about it. In Win2k and NT, it is similar to the registry (you need a special tool), in Win2003, they made it an XML document for easy editing.

If your problem is Database...

Optimize your database access in your code

Use Stored Procedures wherever possible - this keeps the database from having to parse your query, develop a new execution plan, then get your data. Stored Procedures use a cached execution plan, and the only thing to parse are your arguments -- faster, and more secure (no SQL Injection

Trim back your real-time synchronous processing tasks if possible. if you are doing complex inserts into multiple tables, devise a scheme to insert your data into only 1 or 2 processing tables, then schedule a service to go in every X minutes/hours/days to then take the data from the processing tables and do the fancy processing to it and insert it into the "real" tables. Especially good to schedule during off-peak hours if they exist.

Partition your data with multiple SQL Servers this is also known as "Shared-Nothing Clustering"

Gosh, sounds like XML-RPC.

Guess which came first?

If you're concerned about MS 'mostly' controlling SOAP, as you should be, then you'd likely be interested in XML-RPC .

Is everybody still inventing his own application layer protocol?

Stateless, connectionless servers are a good idea (HTTP, NFS, SMTP); for this reason, most people are going with web services calls (XML-RPC or SOAP) and using HTTP pipelining to erase the TCP connection negotiation overhead. This solves 95% of the problems that BEEP is designed for.

If you're still convinced that you really, really, really need a stateful connection, XATP is much simpler and gets the job done just as well as BEEP.

I went to XML-RPC home page and what do I see? The sign of the Holy Spirit in the top right corner. Good God XML-RPC is a truly blessed architecture! Halleluyah!

SOAP is interesting, but getting bloated. There's no reason to use something that heavy for simple messaging. XMLRPC (from which the SOAP bubble formed) would probably work just as well.